The control of systems via data networks is well known; the Simple Network Management Protocol (SNMP) is a popular example of a standardized system in which a control software program, a “manager” interacts over a network with one or more other software programs, or “agents”, which monitor and/or control apparatus or system elements. Standard software for implementing SNMP agents and managers (or key parts of them) is commercially available so that SNMP-based control systems can be implemented with a minimum of additional programming work.
In SNMP the values of simple data “objects” are reported from an agent to a manager, or values are set by an agent in response to instructions from a manager. Typical data objects may be parameters characterizing a process, warning messages or the states of switches, controls etc. In the protocol for communication between manager and agent, an object is identified by an object identifier “OID” which comprises a string of numbers separated by dots. These numbers can be interpreted as nodes in a tree, and a sub-tree starting at a particular node can be allocated to a particular company or organization which then determines the meaning of those nodes.
FIG. 1 shows an example of the definition of a node in this way. If there are several instances of a object corresponding to a particular node it is usual to put them on the same level of the hierarchy. In FIG. 1 the OIDs:
1.14.9
1.14.11
1.14.12
could represent the same class of object.
In the SNMP protocol particular nodes may be addressed by giving the full OID or, alternatively, a “next” node or nodes may be addressed. In FIG. 1 the next node after 1.7 is 1.14; and, the next node after 1.14 is 1.14.9.
The interpretation of OIDs is defined in management information databases or “MIBs”. The information in a MIB enables the OID for a particular control data object to be determined and defines the type and format of the data object. SNMP managers and agents generally require access to MIBs characterizing all the objects they deal with. Usually a specific MIB is written for an agent at a particular address on a network.
Where a range of products is to be designed with SNMP control in mind it is generally necessary for a new MIB to be written and made available every time a new product is added to the range. This is particularly so if commercially available general-purpose SNMP software is to be used. If the products in the range have similar functions and the differences between them are small, it may be possible to write a generic MIB applicable to all of them. However, where the product range may encompass arbitrary functionality, this is impossible.
In some industries, for example audiovisual content creation, it is common for functional elements to be made available as modules or sub-assemblies, one or more of which can be housed in a general-purpose enclosure, which provides common support functions (such as power and control). If such a general-purpose enclosure provides an SNMP control agent it will typically be necessary for a customized MIB to be available to it and the content of that MIB must depend on the particular functional elements installed in the particular general-purpose enclosure. Thus if the modules of the enclosure are changed, it is typically necessary for a new MIB to be used by that enclosure, or the agent for that enclosure. The flexibility of the modular system is therefore reduced.